Event detection in computer systems allows management software to reliably identify the components and configuration of a computer system, to respond to hardware failures, and/or to otherwise monitor and improve the operation of the system. The range of events that may be detected by computer systems and reported to management or other subscriber applications is essentially unlimited. Some examples of computer detectable events include disk drive activity and errors, installation or de-installation of hardware components, network server activities and failures, and network security breaches. Such events may be generated by event providers as they occur, or detected via a polling operation.
Events are often detected by drivers associated with hardware components, operating system software, and instrumentation specifically designed to monitor hardware or software. As the number of hardware components, the complexity of software, and the size of computer networks continues to increase, it has become increasingly difficult to create management and other applications that can become aware of the occurrence of events in hardware and software components in an efficient manner. For example, a typical application is not normally interested in being notified of every event that is detected in system or network, and thus some form of selective notification is needed to improve efficiency. At the same time, it is often critical that an application does not miss an event in which it is interested. As a result, the processes for detecting and reporting the occurrence of events have become increasingly important and complex.
U.S. patent application Ser. No. 09/175,592, entitled “Using Query Language for Provider and Subscriber Registrations,” filed Oct. 20, 1998, which is a continuation-in-part of U.S. patent application Ser. No. 09/158,171, hereby incorporated by reference herein in their entireties, describe anary (not necessarily binary) filtering trees which are efficiently used by an event filtering mechanism and/or event providers to selectively report events to event subscribers that have registered for notification of those events. The filtering trees are constructed from queries received from event subscribers, and arranged such that traversing one or more appropriate trees using actual parameters accompanying an event determines whether a query is satisfied, i.e., whether a given subscriber should be notified. Moreover, multiple trees may be merged into a single tree. In this manner, a relatively large numbers of queries may be evaluated in a single traversal of a single tree.
In general, the filtering trees are arranged as hierarchies of nodes, with parent nodes representing parameters, and each parent node capable of having multiple data points corresponding to the values of a parameter to be evaluated. Depending on the result of the evaluation against the actual parameter values for a given event instance, the parent node branches to an appropriate child node representing further parameters to be evaluated, or to a leaf node which specifies whether a query is (or which queries are) satisfied by the event parameters and actual values. The subscribers that correspond to the satisfied queries are then rapidly determined. Note that the nodes and/or data points may be strings or other values, for example, strings that represent hardware device types.
By way of example, the filtering mechanism may receive a query from an event subscriber, such as an application or operating system, instructing the filtering mechanism to notify the subscriber whenever particular type of modem is added (but no other types of modems or hardware). The event filtering mechanism may then construct or modify an existing filtering tree to filter events so as to find this query when this type of modem is detected. For example, such a tree may include a first-level node that branches to a lower node when hardware change events are detected. Below the hardware node, a second-level child node may be present with data points, one of which represents modems, and others which represent other types of hardware devices. Below the node that represents the general class of devices, and pointed to by the data point that represents modems, a third-level child node may include data points representing particular types of modems. The particular type of modem being queried for may point to a leaf node, for example, that lists the satisfied query (along with any other queries that are satisfied). Alternatively, the leaf node may list the subscribers to be notified, or a set of true/false values that correspond to a set of queries.
While the use of filtering trees is thus highly efficient in event filtering operations, a tree may grow exponentially when representing queries having multiple parameters. For example, consider a tree having a node with data points that represent many possible values for an “X” parameter, e.g., two, four, nine, sixteen and twenty-eight. Every “X” node may have multiple possible outcomes, e.g., if one “X” node represents the value of two, the node may branch three different ways for an actual parameter value, i.e., one branch to handle less than two, a second for equal to two, and a third for greater than two. Note that the “less than” branch of the next highest “X” data point (e.g., four) will point to the “greater” than branch of the nearest value below (e.g., two), whereby each level has 2n+1 possible outcomes (where n is the number of data points on a node). When multiple parameters are being evaluated, some or all of the “X” node outcomes may branch to a lower-level node representing a “Y” parameter. This node also has data points with 2n+1 possible outcomes, some or all of which may branch to nodes for evaluating a still lower-level “Z” parameter, and so on. While highly efficient to traverse, such a filtering tree may consume a significant amount of storage.